In a 3G network as illustrated in FIG. 1, radio base stations 102 are controlled by Radio Network Controllers (RNCs) 103. I.e., each RNC 103 controls one or more radio base stations 102. The radio base stations (RBSs) 102 and the RNCs 103 constitute a Radio Access Network (RAN). The RAN is further connected via the RNCs to a Core Network (CN) 104. FIG. 1 also illustrates User Equipments (UEs) 101 communicating wirelessly with one or more RBSs 102.
Some of the signaling between the User Equipments and the Radio Access Network (RAN) is transmitted between the UE and the Serving RNC transparently over the radio base stations (RBSs). An example of such signaling is Radio Resource Control signaling. In FIG. 2, an RRC connection request is sent 201 from the UE to the RNC and the RNC responds 202 with a RRC connection setup or reject.
In some scenarios, parts of the RNC get overloaded with huge number of Radio Resource Control (RRC) connection requests from the UEs, typically generated by applications on Smart Phones. When the RNCs are overloaded, they have to spend quite some processing power on just answering RRC connection requests by sending RRC rejections. A smartphone is a handheld device with applications (APPs), which generate traffic in the background, without the explicit knowledge of the user. The applications generate traffic by themselves, polling data bases, positioning updates, etc.
The load on the network nodes increase with the increased number of Smart Phones as the difference between a human being and an application in a Smart Phone is that the application does not give up upon reception of RRC connection reject, which a human being normally does after just a few attempts.
An example of an implementation is to let the RNC reject a certain percentage of the RRC requests that the RNC node can not proceed with. The rejections are done early in the RNC software code, but the RNC still consumes RNC processing power and RRC signaling over the Iub interface with these RRC connection requests and rejections. In the existing solution RRC requests are rejected with a percentage between 0% and 80%, in steps of 10%. The RNC load is evaluated every 5 seconds.
At high RNC load, it is of course devastating to give a further portion of the processing power spent on rejecting RRC connection requests. The higher the excessive load is, the higher is the processing power that the RNC needs to spend on answering RRC connection requests with RRC connection rejections.